Apptronik Apollo: Apollo 2 Training and Apollo 3 Plans

Apollo is no longer one robot

The cleanest way to understand Apptronik in August 2026 is to stop treating Apollo as a single, finished machine. Apollo is now a sequence of hardware generations wrapped in a larger learning system. The original robot introduced the industrial concept. Apollo 2 is collecting the experience. Apollo 3 is supposed to turn that experience into a commercial fleet.

That distinction matters because the old language around humanoids encouraged a wonderfully simple picture: a human-shaped machine arrives at a factory, watches a worker, learns the task, and gets on with the shift. Apptronik's current story is more grounded and more interesting. It involves teleoperation, repeated task practice, physical data infrastructure, customer workflows, safety choices, hardware configurations, AI training, and the slow accumulation of operational evidence.

Apollo 2 is the present tense

On June 30, Apptronik unveiled Apollo 2 as the current version of its humanoid platform. The company described it as a data-collection and training machine, not the broadly available commercial endpoint. Apollo 2 comes in bipedal and wheeled-base forms and has already been working for more than a year, according to Apptronik.

The machines operate inside Robot Park, the company's expanded training facility in Austin, and at selected customer and partner sites. Their work spans logistics, manufacturing, retail, and other customer-driven activities. Some execution is autonomous. Some is teleoperated. Both modes create data that Apptronik and Google DeepMind can use to improve Gemini Robotics models.

This is an important correction to the way Apollo is often discussed. The robot is active in real environments, but activity is not the same thing as a generally available product, and task data is not the same thing as unattended production. Apollo 2 is a bridge between prototypes and the fleet Apptronik wants to sell next.

Apollo 3 carries the commercial promise

Apptronik says everything learned through Apollo 2 is feeding Apollo 3, which it calls its next-generation commercial product. That sentence should sit near the top of every 2026 evaluation. It tells buyers what is real today and what is still ahead.

It also introduces a healthy procurement question: what exactly is being evaluated? A demonstration on original Apollo hardware, a data-collection exercise on Apollo 2, and an expected Apollo 3 deployment are not interchangeable. They may differ in locomotion, hands, sensors, compute, software, safety functions, battery systems, service procedures, and performance.

A buyer should insist that every proposal names the hardware generation, base, end effector, software build, autonomy mode, remote-support model, and included safety functions. Humanoid robotics is moving too quickly for the product name alone to be a sufficient configuration.

The original specifications still need a label

The first Apollo was introduced at roughly 5 feet 8 inches and 160 pounds, with the ability to lift 55 pounds. Apptronik also described a hot-swappable battery with four hours of runtime. Those numbers made the robot legible: human scale, meaningful box-handling capacity, and a battery design intended to avoid long plug-in pauses.

They remain useful facts, but they belong to the original design. Apptronik has not published a complete Apollo 2 specification sheet that confirms every number carries forward unchanged. It has published even less detail about Apollo 3. A careful page should therefore resist the temptation to blend three generations into one permanent specification table.

This is not pedantry. A payload rating without reach, pose, speed, duty cycle, grip geometry, and safety constraints can mislead. Four hours of nominal runtime does not reveal productive cycles per charge, swap labor, charger capacity, thermal limits, or battery degradation. A useful procurement conversation begins where the headline number ends.

Robot Park is the most revealing product

Apptronik's nearly 90,000-square-foot Robot Park may prove more consequential than any single stage demonstration. It is a physical data factory where fleets repeat customer tasks, collect demonstrations, test autonomy, and expose hardware and software to the untidy edges of industrial work.

The company says related data-collection workflows are also operating at Google DeepMind and customer locations including Mercedes-Benz and GXO. That creates a potentially valuable loop: observe a real task, capture teleoperated and autonomous experience, train the model, test the new behavior, and repeat across hardware in multiple environments.

This is what embodied AI needs. Internet-scale language models can learn from text that already exists. A robot model needs grounded examples of force, motion, object contact, failure, recovery, and variation. Somebody must create that physical experience, label it well, and decide which mistakes are safe enough to learn from.

Robot Park does not solve the commercial case by itself. It does, however, show that Apptronik understands the bottleneck. The race is not simply to build a graceful body. It is to build a reliable system for turning human work into robot capability.

Teleoperation is work, not a footnote

Apptronik explicitly says Apollo 2 data comes from a combination of teleoperation and autonomous execution. That is not an embarrassment. Teleoperation is one of the practical ways to demonstrate tasks, handle rare exceptions, collect high-quality trajectories, and keep early systems productive while autonomy improves.

The problem begins when viewers cannot tell which mode produced the result. A video of a robot completing a task may show an autonomous policy, a human operator, a scripted sequence, or a blend of all three. Each can be technically valuable, but they answer different commercial questions.

For buyers, operator burden belongs on the same dashboard as robot throughput. Measure teleoperation minutes, interventions, resets, remote-support calls, teaching time, recovery duration, and the number of robots one person can supervise. If those figures are missing, the labor model is missing too.

Gemini Robotics is a path, not a magic layer

The Google DeepMind partnership gives Apptronik one of the strongest AI relationships in the humanoid field. Apollo 2 supplies a physical platform and a stream of task data. Gemini Robotics supplies models intended to reason and act in the physical world. Together, the companies are trying to create a learning loop that improves across deployments.

That is strategically meaningful, but it should not be translated into a claim that Apollo can already do any task after a conversation. General-purpose robotics remains a demanding integration problem. Perception must survive glare, occlusion, clutter, and damaged packaging. Manipulation must handle uncertain contact. Planning must respect people, equipment, and cycle times. Recovery must work when the world refuses to match the training distribution.

The appropriate test is still the delivered task on the delivered software build. Ask what the robot can do autonomously, how often it asks for help, what happens after a failed grasp, and how a new behavior is validated before it reaches the floor. A prestigious model partner improves the development path. It does not eliminate acceptance testing.

The wheeled base deserves more attention

Humanoid coverage tends to fixate on walking because walking looks like the future. Apptronik's modular approach offers a quieter and often more practical option: put the upper body on a wheeled base.

The company says the wheeled Apollo 2 is designed to conform with existing safety standards for industrial mobile robots. It can collect manipulation and workflow data while avoiding some of the balance, fall, energy, and recovery challenges of legs. In a flat, structured warehouse or factory, that may be the more rational machine.

The bipedal configuration still matters when the environment genuinely demands feet, human-like access, or data about legged operation. But legs should earn their place in the business case. If wheels cover the route, meet the workstation, and improve uptime, the less cinematic configuration may produce the better deployment.

A modular robot should permit that choice. It should not turn modularity into a slogan. Buyers need to know how the configurations differ in task reach, speed, charging, safety certification, service, calibration, spares, and software support.

Mercedes-Benz provides a concrete task map

Apptronik's Mercedes-Benz agreement remains one of Apollo's most specific industrial references. The announced work explored bringing parts to production workers, delivering assembly kits, inspecting components, and moving totes of kitted parts later in the manufacturing process.

These are sensible early tasks. They combine mobility and manipulation without asking the robot to perform the most dexterous step in vehicle assembly. They are also easy to underestimate. A tote route includes people, carts, timing windows, narrow clearances, variable load placement, traffic rules, and recovery when the destination is blocked.

The value of the Mercedes-Benz relationship is not that it proves every Apollo deployment will work. It gives Apptronik exposure to a serious production environment and a family of tasks that can be measured. The next useful disclosures would be productive hours, intervention frequency, throughput, item damage, safety stops, and the portion of each workflow completed without human rescue.

GXO tests the warehouse thesis

GXO's early proof of concept focused on labor-intensive distribution-center work. The announced program began with lab evaluation intended to fine-tune the system before deployment to a United States distribution center once ready.

That wording is worth preserving. It describes a development progression, not a finished multi-site rollout. Warehouse automation lives or dies on throughput, uptime, exception handling, and the economics of peak demand. A general-purpose body is valuable only if it can handle enough of the variation without turning every exception into a remote-support ticket.

GXO also gives Apptronik a demanding comparison set. Distribution centers already use conveyors, autonomous mobile robots, robotic arms, sortation, goods-to-person systems, and highly tuned software. Apollo does not compete with an empty floor. It must win a task that established automation cannot handle as flexibly or economically.

Jabil may be the most important partner

Jabil is both manufacturing partner and prospective user. The companies announced plans for Jabil to build Apollo robots and integrate them into selected Jabil operations, including production lines involved in making Apollo itself. Proposed tasks include inspection, sorting, kitting, lineside delivery, fixture placement, and simple sub-assembly.

This arrangement can create an unusually useful feedback loop. Manufacturing exposes design weaknesses quickly. A difficult cable route, slow calibration step, fragile connector, inconsistent actuator, or awkward service procedure becomes visible when the manufacturer must repeat it at scale. Deploying robots inside that environment can also reveal which tasks are stable enough for automation and which still demand human judgment.

Jabil brings global production capability, but capability is not the same as output. Apptronik has not published Apollo production volume, yield, delivery cadence, field reliability, service capacity, or unit economics. The partnership strengthens the path to scale. It does not prove scale has already arrived.

The funding buys time to solve hard problems

In February 2026, Apptronik said its Series A had grown beyond $935 million, bringing total capital raised close to $1 billion. The company said the new capital would support production, deployment, customer use cases, training facilities, and data collection.

That is a formidable war chest for a hardware company facing expensive iteration. Humanoids require more than an AI team. They require actuators, batteries, hands, sensors, compute, manufacturing tooling, supply-chain depth, safety engineering, field service, customer integration, and a place to collect physical experience.

Funding is still an input. The outcome buyers need is a supportable machine with predictable behavior and believable economics. The larger the financing announcement, the more important it becomes to keep product evidence separate from corporate momentum.

Safety is a system property

Apptronik has long emphasized human-centered design, force control, visible communication, and operation around people. Apollo's face and chest displays were designed to make status and intent easier to read. Apollo 2's wheeled configuration is positioned around established industrial mobile-robot standards, while the bipedal configuration is being refined for safety and reliability through real-world operation.

These are thoughtful ingredients. None is a universal safety certificate. A robot carrying a box can pinch, collide, drop a load, block an aisle, lose localization, or fall. The risk changes with speed, reach, payload, end effector, floor condition, traffic, software mode, and the worker's task.

A serious deployment needs a task-specific risk assessment, validated protective functions, safe stopping behavior, emergency procedures, change control, incident reporting, worker training, and clear ownership. Friendly styling may help people interpret a machine. It cannot carry the assurance argument on its own.

Price remains private

Apptronik does not publish an Apollo list price, a standard subscription, or a complete commercial package. It also has not published public Apollo 3 ordering, delivery, warranty, support, or service terms. The old habit of quoting an aspirational car-like future price as if it were today's procurement number should end.

The relevant number is total cost per successful unit of work. That includes the robot, end effectors, integration, mapping, workflow changes, safety engineering, charging, spare batteries, networks, supervision, teleoperation, maintenance, software, support, downtime, and whatever fallback process remains necessary.

Custom pricing is normal at this stage. Hidden economics are still a limit. A pilot should therefore include a path to a real commercial quote and a model for cost at the expected fleet size. Otherwise, the evaluation may prove technical possibility without answering whether the process should be deployed.

Workers belong inside the experiment

Apptronik frames Apollo as a way to take physically demanding, repetitive, or hazardous work from people. That goal is most credible when workers participate in task selection, hazard review, training, exception design, and evaluation. The people doing the job understand its invisible variation. They know which tote sticks, which aisle clogs, which label peels, and which recovery shortcut creates tomorrow's injury.

A human-centered robot program should measure more than cycle time. It should ask whether ergonomic exposure falls, whether new monitoring work appears, whether the robot's behavior is legible, whether stoppages create stress, and whether employees have a safe way to report problems.

The best early use case may not replace a job. It may remove the worst movement inside a job, create a safer handoff, or keep a line supplied without asking a person to walk the same route hundreds of times. That can be meaningful automation even before broad autonomy arrives.

The evidence buyers should request

Apollo's next chapter will be decided by operational data. Buyers should ask for successful task cycles per hour, autonomous share, teleoperation minutes, human interventions, mean time between stoppages, mean recovery time, battery runtime under load, swap and charge burden, damaged-item rate, safety stops, maintenance hours, and performance across full shifts.

They should also ask which failures are excluded from the metric. A robot that completes 98 percent of grasps can still be a poor system if the remaining 2 percent block the aisle and demand a specialist. A beautiful average can conceal a costly tail.

Evidence should be generation-specific and configuration-specific. Original Apollo numbers should not stand in for Apollo 2. Apollo 2 training should not stand in for Apollo 3 product performance. A wheeled result should not be presented as a bipedal result. Teleoperated success should not be labeled autonomous.

The WhatAI view

Apptronik has assembled one of the more credible industrial ecosystems in humanoid robotics. Mercedes-Benz supplies manufacturing use cases. GXO supplies warehouse reality. Jabil supplies production discipline. Google DeepMind supplies a major embodied AI partnership. NVIDIA contributes simulation and robot-learning infrastructure. Robot Park gives the company a place to turn those relationships into repeatable data.

The most encouraging part of the 2026 story is also the least theatrical: Apollo 2 is doing the work required to make a future machine useful. Apptronik is collecting demonstrations, comparing mobility configurations, testing customer tasks, and building the feedback loop that a commercial fleet will need.

The limit is equally clear. Apollo 3 is still forthcoming. Public pricing is absent. Standard ordering and delivery are absent. Detailed field metrics are absent. Apptronik has a strong path to commercialization, but a path is not a finished market.

For an enterprise with the right task, budget, data discipline, and tolerance for co-development, Apollo is worth a serious conversation. For a buyer seeking a finished catalog product with transparent economics and proven unattended shifts, the honest answer is to watch Apollo 3 and ask for the numbers. The next breakthrough will not be another graceful video. It will be a boring report from a real facility showing that the robot kept working when nobody was watching the demo.

WhatAI Decision Box

Apptronik Apollo is an industrial humanoid robotics platform aimed at manufacturing, logistics, and warehousing. Apollo 2 is the current data-collection and training generation, while Apptronik describes Apollo 3 as the forthcoming commercial fleet.

Apollo combines human-scale hardware, modular wheeled and bipedal configurations, teleoperation, autonomous execution, and embodied AI research. Apptronik has announced work with Google DeepMind, Mercedes-Benz, GXO, Jabil, and NVIDIA, but it has not published a list price or general ordering process.

Share firsthand Apollo evaluations, task data, safety observations, integration requirements, and deployment economics. Identify the hardware generation, configuration, site, task, supervision level, and measurement period so readers can distinguish a demonstration from sustained production use.

Use Cases

Pricing varies by plan and region — see current pricing.

Plan features change — last updated: 2026-08-16.

Apptronik Apollo Community Discussions

Explore community discussions. Ask and answer questions on Apptronik Apollo to grow and learn together.

Apptronik Apollo Pros & Cons

How to Get Results with Apptronik Apollo: Step-by-Step Workflow

1. Define one production problem

   Choose a repetitive, measurable task with clear value, stable objects, known travel paths, and a credible reason to use a humanoid or modular mobile manipulator instead of established automation.

2. Document the real environment

   Capture object dimensions and weights, rack and workstation geometry, floor conditions, lighting, traffic, shift patterns, handoffs, exceptions, network constraints, and required safety zones.

3. Request the exact configuration

   Confirm whether the evaluation uses Apollo, Apollo 2, or Apollo 3; a wheeled or bipedal base; which end effector; which software release; and what teleoperation or remote support is included.

4. Build the safety case

   Run a task-specific risk assessment, identify applicable standards, validate protective functions, define separation and stopping behavior, establish emergency procedures, and train affected workers.

5. Create a measured baseline

   Record current throughput, labor time, ergonomic exposure, error rate, damage, downtime, queueing, and cost so the robot is compared with the actual process rather than an idealized demonstration.

6. Start in a bounded cell

   Use a limited object set, short route, controlled traffic, supervised shifts, explicit success criteria, and conservative speeds while logging every stop, retry, intervention, and recovery.

7. Test exceptions deliberately

   Introduce misplaced items, occlusion, damaged packaging, congestion, low battery, dropped objects, network loss, localization errors, blocked paths, and human interruption under controlled conditions.

8. Measure operator burden

   Track teleoperation minutes, remote-support calls, resets, teaching time, battery changes, charging, maintenance, cleaning, and the skill level required to keep the workflow productive.

9. Calculate task economics

   Model cost per successful cycle using the quoted commercial terms plus integration, facilities, safety work, supervision, support, energy, spares, maintenance, and expected utilization.

10. Gate any expansion

    Expand only after the robot meets agreed reliability, safety, throughput, intervention, recovery, and cost targets over representative shifts, and retain a fallback process for failure or service outages.

Apptronik Apollo Gotchas and Limits to Know Before You Start

• Apollo 2 is described as a data-collection and training platform, while Apollo 3 is the planned commercial fleet.
• Public list pricing, standard ordering, delivery timing, warranty terms, and total-cost data are not available.
• Original Apollo specifications should not be assumed to apply unchanged to Apollo 2 or Apollo 3.
• Partner announcements and Robot Park activity do not disclose fleet size, productive hours, intervention rates, or customer ROI.
• Teleoperation contributes to current data collection, so demonstrations may not represent unattended autonomy.
• A human-shaped robot is not automatically the best automation architecture for every task.
• Bipedal mobility adds balance, fall, energy, maintenance, and safety considerations that a wheeled base may avoid.
• Four-hour battery claims refer to the original Apollo and do not establish usable shift output under a specific duty cycle.
• A 55-pound payload rating does not define reach, speed, grasp stability, duty cycle, or safe payload across every pose.
• Force control and approachable design do not replace a site-specific safety assessment and validated safeguards.
• Objects, packaging, racks, lighting, floor conditions, congestion, and exception rates can materially change performance.
• Integration may require workflow changes, data collection, teleoperation, network access, and dedicated support staff.
• No public general-purpose developer SDK or open marketplace of third-party Apollo applications is documented.
• Future retail, healthcare, eldercare, home, and space uses are roadmap ambitions, not current general availability.

Which Apptronik Apollo Feature Fits Your Use Case

Starter Prompts for Apptronik Apollo

What is Apptronik Apollo?

Apollo is Apptronik's modular humanoid robotics platform for work in human-designed industrial environments. Its initial focus is manufacturing, warehousing, logistics, and retail operations rather than consumer home use.

What is Apollo 2?

Apollo 2 is the current version of the platform announced in June 2026. Apptronik describes it as a data-collection and training robot available in bipedal and wheeled-base configurations, with fleets active at Robot Park and selected customer and partner sites.

Is Apollo 2 the commercial product?

Not in the broad, off-the-shelf sense. Apptronik calls Apollo 2 a training platform and says its data and operating experience are powering Apollo 3, which it describes as the upcoming commercial fleet. Public Apollo 3 release timing and ordering details remain undisclosed.

How much can Apollo carry?

The original Apollo announced in 2023 was rated to lift 55 pounds, or about 25 kilograms. Apptronik has not published a complete Apollo 2 specification sheet, so buyers should not assume every original specification transfers unchanged to Apollo 2 or Apollo 3.

How long does Apollo's battery last?

The original Apollo used hot-swappable batteries rated for four hours each. Apptronik has not publicly provided a complete Apollo 2 battery specification, so runtime, swap time, charger requirements, battery inventory, and duty cycle should be verified for the exact configuration.

Where is Apollo being tested?

Apptronik says Apollo 2 fleets operate at its nearly 90,000-square-foot Robot Park in Austin and at partner locations including Google DeepMind, Mercedes-Benz, and GXO. Jabil is also a manufacturing and validation partner. Site-level fleet counts and production performance metrics are not public.

What does Google DeepMind contribute?

Apptronik and Google DeepMind are working on embodied AI using Gemini Robotics. Apollo 2 generates real-world data through teleoperation and autonomous execution, which is used to train and refine models intended for future deployment. This does not mean every Apollo task is fully autonomous today.

Can Apollo work safely without fencing?

Apptronik presents Apollo as human-centered and uses force control, visual communication, and configuration-specific safety approaches. The wheeled Apollo 2 is designed to align with existing industrial mobile-robot standards. A buyer still needs a site-specific risk assessment, validated safety functions, safe operating procedures, and applicable regulatory review.

How much does Apptronik Apollo cost?

Apptronik does not publish a list price, subscription rate, or standard total-cost model. Enterprise customers need to contact the company and evaluate hardware, integration, training, supervision, charging, maintenance, support, and facility costs together.

Can any business buy Apollo now?

There is no public self-service order page or standard availability schedule. Current access is best understood as direct enterprise engagement, selected pilots, research work, and strategic partnerships while Apptronik develops the forthcoming Apollo 3 commercial fleet.

Related Collaborative Robots (Cobots) & Manufacturing Tools

Explore the Network